Night Owl 6/Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso/045a/qostb229.zip/VIRTUALI.TEC

Text File | 1991-12-26 | 16KB | 319 lines

ID:V1 What is Virtualizing?
Quarterdeck Technical Bulletin #229
by Michael Bolton and Eric Wieling

Q. What is virtualizing?
Q. What does "virtualize text and graphics" mean?
Q. What does "writes directly to screen" mean?
Q. How can I tell if my program writes directly to screen?
Q. I've set "Runs in background" to Y.  Why isn't my program running in
   background?


Q. What is virtualizing?

Programs can handle display in three ways in DESQview parlance.  These
are explained in more detail below, but briefly,

1) the "well-behaved" application uses DOS or your system's BIOS
   services to display its information;

2) the "DESQview-aware" program writes directly to the screen when not
   running under DESQview, but writes to a special area of memory (under
   DESQview's control) so that DESQview may properly manage display of
   multiple windows.

3) the "misbehaved" application writes directly to the screen hardware
   with no consideration for DESQview or any other multitasking
   environment.

Misbehaved applications present a special problem for most multitasking
environments, in that direct screen-writing can "bleed through" into
foreground windows.   However, on a 386 processor, DESQview 386 (which
is simply DESQview and QEMM running on the same computer) can
"virtualize" misbehaved applications; that is, it can fool these
applications into believing that they have exclusive control of the
screen.  Thus, such applications may be run in background or in a small
window without interfering with the display of other applications.

The first thing to know about virtualizing is that, unless you are
working on a 386, 386SX, or i486 machine, AND using DESQview 386,
virtualizing means little to you; anything less than a 386 is not
capable of virtualizing the screen, and only DESQview and QEMM (which
together comprise DESQview 386) provide the memory-mapping services
that allow this trick to be performed.  This is another of the many
compelling reasons to move to a 386 processor if you have not already
done so.  (For the purposes of this discussion, the 80386SX, the 80386
(also known as the 80386DX), and the i486 are equivalent; all provide
the memory-management features of the 386.)

Now that we've established that we discuss virtualization only when we
refer to a 386, we should look at the way programs display information
on the screen.

From DESQview's perspective, there are two basic types of programs, as
far as display is concerned. The first type of program, the
"well-behaved" program in DESQview parlance, uses DOS or the system's
Basic Input/Output Services (BIOS) to put text on the screen.  The BIOS
gets information from the program, and then puts values into screen
memory addresses; these values are then translated by the display
adapter to show up as the characters that you see on your monitor.
"Well-behaved" applications, then, use resources built into the system
to display information.  To run a program in a small window or in
background, DESQview (without QEMM's help, and on any processor)
intercepts DOS and BIOS calls and places the results into a "virtual
screen."  This is an area of memory, or "buffer," the same size as
screen memory, which, to the application, looks and feels exactly like
the real screen.  The application therefore behaves as it would if it
had the computer all to itself.  The "well- behaved" program believes
that display work has been done, and continues about its business
without complaints.

Applications which display Hercules, CGA, EGA, or VGA graphics (and this
includes all programs with graphical user interfaces) normally do not
use the BIOS.  Because of the greater complexity involved in displaying
graphics, such programs do not have the option of writing directly to a
DESQview memory buffer, nor are there BIOS services efficient enough to
allow such programs to run at a satisfactory speed.  These applications
are therefore, by definition, NOT well-behaved and are called
(predictably) "misbehaved" in DESQview parlance.  This type of program
avoids DOS and the BIOS, and puts text or graphics on the screen itself
by writing values directly into screen memory addresses.

For text-based applications, writing directly to the screen hardware is
considerably faster than using BIOS calls, so many text applications
write directly to in the interests of speed.  Graphics-oriented BIOS
functions are limited in power and flexibility, and in any case are
unacceptably slow, so graphical applications write directly to the
screen.

The DESQview-aware program checks for the presence of DESQview (or
Microsoft Windows, or TopView, an IBM environment with which DESQview is
compatible) and asks for the address of the memory buffer that DESQview
will use to store the program's video information.  The program then
writes directly to DESQview's memory buffer instead of to the video
hardware.  This method produces the same well-governed results as
writing through DOS or the BIOS, and is considerably faster.  This type
of application is called "DESQview-aware."

Writing directly to screen memory addresses eliminates the middleman,
but the catch is that direct-to-screen display information cannot be
intercepted and redirected as easily as BIOS calls.  Under anything
other than DESQview-386, such programs will not run smoothly in
background or in a small window.  These programs interact directly with
the display hardware, and will write outside the borders of their
DESQview windows; if allowed to run in background or in a small window,
these programs will "leak" or "bleed" into the display windows of other
programs.  The alternative is to suspend the operation of this type of
program while it is in background, which is DESQview's default method of
managing such programs.  This is quite satisfactory for those who want
to use DESQview as a task-switching environment, but not for those who
desire multitasking.

Happily, the 386 processor, QEMM-386, and DESQview, all working
together, can trap the direct screen writes of misbehaved text or
graphics programs and redirect the output of these applications to
DESQview's video buffers -- also called "virtual screens," since as far
as the application knows, it is writing to the screen.  This process is
called "virtualizing." The advantage of virtualizing is that, under
DESQview 386, misbehaved text programs and even programs using Hercules,
CGA, EGA, or VGA graphics can run comfortably in background or in a
small window.


Q. What, then, is the difference between "virtualizing text" and
   "virtualizing text AND graphics"?

First, memory usage: a memory buffer for a virtualized text screen only
takes up as much memory (in bytes) as there are places to display a
character on the screen. That works out to 80 (columns) X 25 (rows) X 2
bytes per character (one byte for the character, and the other for its
display attribute), for a total of 4000 bytes.  If you want to create a
virtual screen to catch text-based data, you won't pay much of a memory
penalty.  DESQview uses expanded memory to virtualize video output, and
expanded memory can only be allocated in 16K chunks (called "pages").
Consequently, it costs 16K, rather than 4000 bytes, of expanded memory
to virtualize a text program.  If you want to virtualize graphics,
though, you'll need as much as 272K of available expanded memory,
depending on the graphics mode that the program is using.

Second, there is a difference in the use of the processor's time.  A
virtualized text program is approximately as fast as a nonvirtualized text
program, but virtualizing graphics does take a heavy toll on the processor.
Incidentally, when you are running a virtualized program full-screen and in
foreground, DESQview temporarily suspends virtualization and lets the program
write to the real video memory region; in this circumstance, there is
little extra processor overhead.

Third, it is worth noting that under DESQview 386, even protected mode
programs, also known as DOS-extended programs, can be multitasked,
thanks to a memory-management specification, coauthored by Quarterdeck,
called the Virtual Control Program Interface (VCPI).  It is possible in
most circumstances to virtualize the text output of a program that runs
in protected mode.  This is because most protected mode programs
actually switch into real mode to write text to the screen.  However,
programs which write graphics directly to the screen while in protected
mode cannot be virtualized, so DESQview 386 will by default halt the
operation of such programs when they are not using the full screen.  A
newer specification for multitasking, the DOS Protected Mode Interface,
will allow virtualization of protected-mode programs; future versions of
DESQview and QEMM are expected to support this specification.


Q.  How can I tell if my program is writing directly to screen?

To tell if an application is writing directly to the video hardware
inside DESQview, make the following changes in the application's Change
a Program menu:

1) Set "Writes text directly to screen" to N;

2) Set "Virtualize text/graphics" to N;

3) On the Advanced Options screen, blank out the following four fields
in the "Window Position" section: Starting Height, Starting Width,
Starting Row, and Starting Column.  Put blanks in these fields, not
zeros.

After these changes have been made, open the program. DESQview will
place a small window border on the screen; if the program comes up and
stays within the small window border, it does not write directly to the
screen.  If the program demolishes the window border and takes the full
screen, it is writing directly to the hardware, and should be
virtualized if you wish to run it in background or in a small window.

Q. Why doesn't my program STAY in background?  It bleeds through on to
the screen when it's background; even though I've set "Runs in
background" to Y, the information from this program keeps showing up in
the foreground window.

If it is an application that writes text or graphics directly to screen,
one reason might be that it is not set up to virtualize.  You can amend
this by

1) selecting Change a Program from the DESQview Open Window
   Menu,

2) selecting the program that you want to change, and

3) on page one of the Change a Program Menu, setting "Virtualize text
and graphics" to Y or T.


Q.  When should I virtualize both text and graphics?

If an application does work which you want to continue while the
program is in background or in a small window, and it is a program
that does this work while displaying graphics, set "Virtualize text
and graphics" to Y.

Q. When should I virtualize text only?

1) If you have an application which writes text directly to the screen,
but never uses graphics, set Virtualize to T.  Misbehaved text-based
applications are good candidates for this treatment.

2) If you have an application which does write both text and graphics
directly to the screen, but in which you have no need to run the program
in background while graphics are being displayed, set Virtualize to T. A
good example of this type of program is a word processor or a
spreadsheet which has a graphical element to it (a charting or print
preview module, for example) that you never need to run in background or
in a small window.  Even if you're not virtualizing this type of
program, you can still place your chart or print preview in a small
window -- the program simply halts, while retaining the information on
screen.  You can still use DESQview's screen management to see all the
parts of the screen you like, but the program's operation is suspended
while it's in the small window. Recalculating and printing, since they
usually take place while the screen is in text mode, can typically
continue to run in background in such programs, since the text mode of
the program is being virtualized.

3) If you have an application which writes text in real mode, but writes
graphics to the screen while in protected mode, again set "Virtualize
text and graphics" to T.  Do this because the program can still be
virtualized while it's in text mode, even though it can't be virtualized
while it's displaying graphics.

Q. I've done all these things and my program STILL won't run in
background. What's wrong?

There are a few possibilities.

You may have set "Virtualize Text and Graphics" on Page 1 of the
program's Change a Program Menu to N.

Solution: set Virtualize Text and Graphics to Y

You may simply be out of memory; when DESQview virtualizes an
application's graphics, it can require up to 272K of free expanded
memory.

Solution: make sure that you have enough memory available for
virtualizing.  If you have several applications open, close down one or
more.  You might also want to consider upgrading your system by adding
more memory.

DESQview 386 cannot virtualize if you have set the Expanded Memory Page
Frame to 0 with QEMM's FRAME=NONE or FRAMELENGTH=0 parameters.

Solution: make sure neither of the above parameters are on the QEMM line
in CONFIG.SYS.

Although DESQview can save and restore most video modes, there are a few
that it can't virtualize.

Solution: try using a lower resolution for the program in question. Text
mode, sometimes known as "CGA mode" for some programs, is a good place
to start.  "CGA mode" is something of a misnomer, since you'll
actually still get your normal resolution on an EGA or VGA -- the
program just writes to the screen without being in graphics mode.

To virtualize graphics, you may need more graphics pages.

Solution: on the Advanced Options screen of the Change a Program Menu,
set Graphics Pages to a higher number, such as 2 or 3.

You may not have enough Real Alternate Maps to virtualize a large number
of windows.

Solution:   QEMM must provide DESQview with a Real Alternate Map for
each virtualized window.  Since QEMM's default number of Real Alternate
Maps is 8, if you are using more than 8 windows, you'll be unable to
virtualize window 9.  Close down an application or two, or specify
MAPS=n on the QEMM line in CONFIG.SYS, where n is a number larger than
8.  Numbers larger than 20 are unlikely to be helpful.

Programs that start as part of a DESQview startup script, and are put
into background by the script, may not virtualize if they change video
modes; when the video mode changes, they will be suspended.

Solution: for this type of program, make sure that "Runs in Background"
is set to Y, and is not left blank.

A program may be grabbing a hardware interrupt, and may write directly
to screen from inside its hardware interrupt handler.

Solution: in this unusual circumstance, use Manifest in TSR mode, and
then load your program.  Look at Manifest's First Meg / Interrupts
screen to determine the software interrupt which corresponds to the
hardware interrupt the program is grabbing.  When you want to run this
program under DESQview, use the DESQview startup parameter /HW:nn:V,
where nn is the number, in hexadecimal, of the software interrupt above.
This will allow DESQview to virtualize screen writes that occur
inside the hardware interrupt handler.


Finally, it should be noted that DESQview 386 is presently the only
program in existence that will multitask and virtualize misbehaved DOS
applications which use EGA and VGA graphics.  Virtualization is one of
the principal ways by which DESQview can multitask these applications;
understanding the above ideas about virtualization can help you to take
the greatest advantage of DESQview's power.

This technical note may be copied and distributed freely as long as it is
distributed in its entirety and it is not distributed for profit.
        Copyright (C) 1991 by Quarterdeck Office Systems
             * * *   E N D   O F   F I L E    * * *